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Description 

SYSTEM AND METHOD FOR SECURING 
RF TRANSACTIONS USING A RADIO 
FREQUENCY IDENTIFICATION DEVICE 
INCLUDING A TRANSACTIONS COUNTER 

Cross Reference to Related Applications 

[0001] This invention is a continuation in part of and claims pri- 
ority to U.S. Patent Application No. 10/192,488, entitled 
"SYSTEM AND METHOD FOR PAYMENT USING RADIO FRE- 
QUENCY IDENTIFICATION IN CONTACT AND CONTACT- 
LESS TRANSACTIONS," filed on July 9, 2002, (which itself 
claims priority to U.S. Provisional Patent Application No. 
60/304,216, filed July 10, 2001), and to U.S. Patent Appli- 
cation No. 10/340,352, entitled "SYSTEM AND METHOD 
FOR INCENTING PAYMENT USING RADIO FREQUENCY 
IDENTIFICATION IN CONTACT AND CONTACTLESS TRANS- 
ACTIONS," filed January 10, 2003 (which itself claims pri- 
ority to U.S. Provisional Patent Application No. 



60/396577, filed July 16, 2002), all of which are incorpo- 
rated herein by reference. 
Field of Invention 

[0002] This invention generally relates to a system and method 

for securing a Radio Frequency (RF) transaction using a RF 

operable device, and more particularly, to securing a RF 

transaction using a Radio Frequency Identification (RFID) 

device including a transactions counter. 
Background of Invention 

[0003] Ljke barcode and voice data entry, RFID is a contactless 
information acquisition technology. RFID systems are 
wireless, and are usually extremely effective in hostile en- 
vironments where conventional acquisition methods fail. 
RFID has established itself in a wide range of markets, 
such as, for example, the high-speed reading of railway 
containers, tracking moving objects such as livestock or 
automobiles, and retail inventory applications. As such, 
RFID technology has become a primary focus in auto- 
mated data collection, identification and analysis systems 
worldwide. 

[0004] of late, companies are increasingly embodying RFID data 
acquisition technology in a fob or tag for use in complet- 



ing financial transactions. Atypical fob includes a 
transponder and is ordinarily a self-contained device 
which may be contained on any portable form factor. In 
some instances, a battery may be included with the fob to 
power the transponder, in which case the internal circuitry 
of the fob (including the transponder) may draw its oper- 
ating power from the battery power source. Alternatively, 
the fob may exist independent of an internal power 
source. In this instance the internal circuitry of the fob 
(including the transponder) may gain its operating power 
directly from an RF interrogation signal. U.S. Patent No. 
5,053,774, issued to Schuermann, describes a typical 
transponder RF interrogation system which may be found 
in the prior art. The Schuermann patent describes in gen- 
eral the powering technology surrounding conventional 
transponder structures. U.S. Patent No. 4,739,328 dis- 
cusses a method by which a conventional transponder 
may respond to a RF interrogation signal. Other typical 
modulation techniques which may be used include, for 
example, ISO/IEC 14443 and the like. 
[0005] | n the conventional fob powering technologies used, the 
fob is typically activated upon presenting the fob in an in- 
terrogation signal. In this regard, the fob may be activated 



irrespective of whether the user desires such activation. 
Alternatively, the fob may have an internal power source 
such that interrogation by the reader to activate the fob is 
not required. 

[0006] one of the more visible uses of the RFID technology is 
found in the introduction of Exxon/Mobil's Speedpass® 
and Shell's EasyPay® products. These products use 
transponders placed in a fob or tag which enables auto- 
matic identification of the user when the fob is presented 
at a Point of Sale (POS) device. Fob identification data is 
typically passed to a third-party server database, where 
the identification data is referenced to a customer (e.g., 
user) credit or debit account. In an exemplary processing 
method, the server seeks authorization for the transaction 
by passing the transaction and account data to an autho- 
rizing entity, such as for example an "acquirer" or account 
issuer. Once the server receives authorization from the 
authorizing entity, the authorizing entity sends clearance 
to the point of sale device for completion of the transac- 
tion. 

[0007] Minimizing fraud transactions in the RFID environment is 
typically important to the account issuer to lessen the loss 
associated with fraudulent RFID transaction device usage. 



One conventional method for securing RFID transactions 
involves requiring the device user to provide a secondary 
form of identification during transaction completion. For 
example, the RFID transaction device user may be asked 
to enter a personal identification number (PIN) into a key- 
pad. The PIN may then be verified against a number asso- 
ciated with the user or the RFID transaction device, where 
the associated number is stored in an account issuer 
database. If the PIN number provided by the device user 
matches the associated number, then the transaction may 
be cleared for completion. 
[0008] one problem with the conventional method of securing an 
RFID transaction is that the time for completing the trans- 
action is increased. This is true since the RFID device user 
must delay the transaction to provide the alternate identi- 
fication. As can be seen, this defeats one real advantage 
of the RFID transaction device, which is to permit expedi- 
ent completion of a transaction since the account infor- 
mation may be passed to a reader without merchant in- 
volvement. 

[0009] As such, a need exists for a method of securing RFID 
transaction which does not increase the time needed to 
complete a transaction, and which method may be used 



without device user intervention. 
Summary of Invention 

[0010] Described herein is a system and method for securing 

RFID transactions which addresses the problems found in 
conventional transaction securing methods. The securing 
method described herein includes providing a RFID device 
including a transaction counter which may generate an in- 
dicia corresponding to the number of transactions con- 
ducted using a particular RFID transaction device. These 
features and other advantages of the system and method, 
as well as the structure and operation of various exem- 
plary embodiments of the system and method, are de- 
scribed below. 
Brief Description of Drawings 

[0011] The accompanying drawings, wherein like numerals depict 
like elements, illustrate exemplary embodiments of the 
present invention, and together with the description, serve 
to explain the principles of the invention. In the drawings: 

[0012] Figure 1 illustrates an exemplary RFID-based system de- 
picting exemplary components for use in RFID transaction 
completion in accordance with the present invention; and 

[0013] Figure 2 illustrates an exemplary method for securing a 



RFID transaction using a counter-generated indicia in ac- 
cordance with the present invention. 
Detailed Description 

[0014] The present invention may be described herein in terms of 
functional block components, screen shots, optional se- 
lections and various processing steps. Such functional 
blocks may be realized by any number of hardware and/or 
software components configured to perform to specified 
functions. For example, the present invention may employ 
various integrated circuit components (e.g., memory ele- 
ments, processing elements, logic elements, look-up ta- 
bles, and the like), which may carry out a variety of func- 
tions under the control of one or more mircroprocessors 
or other control devices. Similarly, the software elements 
of the present invention may be implemented with any 
programming or scripting language such as C, C+ + , Java, 
COBOL, assembler, PERL, extensible markup language 
(XML), JavaCard and MULTOS with the various algorithms 
being implemented with any combination of data struc- 
tures, objects, processes, routines or other programming 
elements. Further, it should be noted that the present in- 
vention may employ any number of conventional tech- 
niques for data transmission, signaling, data processing, 



network control, and the like. For a basic introduction on 
cryptography, review a text written by Bruce Schneier en- 
titled "Applied Cryptography: Protocols, Algorithms, and 
Source Code in C," published by John Wiley & Sons 
(second edition, 1996), herein incorporated by reference. 
[0015] | n addition, many applications of the present invention 
could be formulated. The exemplary network disclosed 
herein may include any system for exchanging data or 
transacting business, such as the internet, an intranet, an 
extranet, WAN, LAN, satellite communications, and/or the 
like. It is noted that the network may be implemented as 
other types of networks, such as an interactive television 
network (ITN). 

[0016] Further still, the terms "Internet" or "network" may refer to 
the Internet, any replacement, competitor or successor to 
the Internet, or any public or private inter-network, in- 
tranet or extranet that is based upon open or proprietary 
protocols. Specific information related to the protocols, 
standards, and application software utilized in connection 
with the Internet may not be discussed herein. For further 
information regarding such details, see, for example, Dilip 
Naik, "Internet Standards and Protocols" (1998); "Java 2 
Complete", various authors, (Sybex 1999); Deborah Ray 



and Eric Ray, "Mastering HTML 4.0" (1997); Loshin, "TCP/ 
IP Clearly Explained" (1997). All of these texts are hereby 
incorporated by reference. 

[0017] By communicating, a signal may travel to/from one com- 
ponent to another. The components may be directly con- 
nected to each other or may be connected through one or 
more other devices or components. The various coupling 
components for the devices can include but are not lim- 
ited to the Internet, a wireless network, a conventional 
wire cable, an optical cable or connection through air, wa- 
ter, or any other medium that conducts signals, and any 
other coupling device or medium. 

[0018] where required, the system user may interact with the 

system via any input device such as, a keypad, keyboard, 
mouse, kiosk, personal digital assistant, handheld com- 
puter (e.g., Palm Pilot®, Blueberry®), cellular phone and/or 
the like. Similarly, the invention could be used in conjunc- 
tion with any type of personal computer, network com- 
puter, work station, minicomputer, mainframe, or the like 
running any operating system such as any version of Win- 
dows, Windows NT, Windows 2000, Windows 98, Windows 
95, MacOS, OS/2, BeOS, Linux, UNIX, Solaris or the like. 
Moreover, although the invention may frequently be de- 



scribed as being implemented with TCP/IP communica- 
tions protocol, it should be understood that the invention 
could also be implemented using SNA, IPX, Appletalk, IPte, 
NetBIOS, OSI or any number of communications protocols. 
Moreover, the system contemplates the use, sale, or dis- 
tribution of any goods, services or information over any 
network having similar functionality described herein. 
[0019] a variety of conventional communications media and pro- 
tocols may be used for data links providing physical con- 
nections between the various system components. For ex- 
ample, the data links may be an Internet Service Provider 
(ISP) configured to facilitate communications over a local 
loop as is typically used in connection with standard mo- 
dem communication, cable modem, dish networks, ISDN, 
Digital Subscriber Lines (DSL), or any wireless communi- 
cation media. In addition, the merchant system including 
the POS device 106 and host network 108 may reside on a 
local area network which interfaces to a remote network 
(not shown) for remote authorization of an intended 
transaction. The POS 106 may communicate with the re- 
mote network via a leased line, such as a Tl, D3 line, or 
the like. Such communications lines are described in a va- 
riety of texts, such as, "Understanding Data Communica- 



tions," by Gilbert Held, which is incorporated herein by 
reference. 

[0020] a transaction device identifier, as used herein, may in- 
clude any identifier for a transaction device which may be 
correlated to a user transaction account (e.g., credit, 
charge debit, checking, savings, reward, loyalty, or the 
like) maintained by a transaction account provider (e.g., 
payment authorization center). A typical transaction ac- 
count identifier (e.g., account number) may be correlated 
to a credit or debit account, loyalty account, or rewards 
account maintained and serviced by such entities as 
American Express, Visa and/or MasterCard or the like. 

[0021] jo facilitate understanding, the present invention may be 
described with respect to a credit account. However, it 
should be noted that the invention is not so limited and 
other accounts permitting an exchange of goods and ser- 
vices for an account data value is contemplated to be 
within the scope of the present invention. 

[0022] a transaction device identifier may be, for example, a six- 
teen-digit credit card number, although each credit 
provider has its own numbering system, such as the fif- 
teen-digit numbering system used by American Express. 
Each company's credit card numbers comply with that 



company's standardized format such that the company 
using a sixteen-digit format will generally use four spaced 
sets of numbers, as represented by the number "0000 
0000 0000 0000." In a typical example, the first five to 
seven digits are reserved for processing purposes and 
identify the issuing bank, card type and, etc. In this exam- 
ple, the last sixteenth digit is used as a sum check for the 
sixteen-digit number. The intermediary eight-to-ten dig- 
its are used to uniquely identify the customer. The ac- 
count number stored as Track 1 and Track 2 data as de- 
fined in ISO/IEC 7813, and further may be made unique to 
the RFID transaction device. 
[0023] | n one exemplary embodiment, the transaction device 
identifier may include a unique RFID transaction device 
serial number and user identification number, as well as 
specific application applets. The transaction device identi- 
fier may be stored on a transaction device database lo- 
cated on the transaction device. The transaction device 
database may be configured to store multiple account 
numbers issued to the RFID transaction device user by the 
same or different account providing institutions. In addi- 
tion, where the device identifier corresponds to a loyalty 
or rewards account, the RFID transaction device database 



may be configured to store the attendant loyalty or re- 
wards points data. 
[0024] The databases discussed herein may be any type of 

database, such as relational, hierarchical, object-oriented, 
and/or the like. Common database products that may be 
used to implement the databases include DB2 by IBM 
(White Plains, New York), any of the database products 
available from Oracle Corporation (Redwood Shores, Cali- 
fornia), Microsoft Access or MSSQL by Microsoft Corpora- 
tion (Redmond, Washington), or any other database prod- 
uct. Databases may be organized in any suitable manner, 
including as data tables or lookup tables. Association of 
certain data may be accomplished through any data asso- 
ciation technique known and practiced in the art. For ex- 
ample, the association may be accomplished either manu- 
ally or automatically. Automatic association techniques 
may include, for example, a database search, a database 
merge, GREP, AGREP, SQL, and/or the like. The association 
step may be accomplished by a database merge function, 
for example, using a "key field" in each of the manufac- 
turer and retailer data tables. A "key field" partitions the 
database according to the high-level class of objects de- 
fined by the key field. For example, a certain class may be 



designated as a key field in both the first data table and 
the second data table, and the two data tables may then 
be merged on the basis of the class data in the key field. 
In this embodiment, the data corresponding to the key 
field in each of the merged data tables is preferably the 
same. However, data tables having similar, though not 
identical, data in the key fields may also be merged by us- 
ing AGREP, for example. 

[0025] | n addition to the above, the transaction device identifier 
may be associated with any secondary form of identifica- 
tion configured to allow the consumer to interact or com- 
municate with a payment system. For example, the trans- 
action device identifier may be associated with, for exam- 
ple, an authorization/access code, personal identification 
number (PIN), Internet code, digital certificate, biometric 
data, and/or other secondary identification data used to 
verify a transaction device user identity. 

[0026] it should be further noted that conventional components 
of RFID transaction devices may not be discussed herein 
for brevity. For instance, one skilled in the art will appre- 
ciate that the RFID transaction device and the RFID reader 
disclosed herein include traditional transponders, anten- 
nas, protocol sequence controllers, modulators/de- 



modulators and the like, necessary for proper RFID data 
transmission. As such, those components are contem- 
plated to be included in the scope of the invention. 

[0027] it should be noted that the transfer of information in ac- 
cordance with this invention, may be done in a format 
recognizable by a merchant system or account issuer. In 
that regard, byway of example, the information may be 
transmitted in magnetic stripe or multi-track magnetic 
stripe format. Because of the proliferation of devices using 
magnetic stripe format, the standards for coding informa- 
tion in magnetic stripe format were standardized by the 
International Standards Organization (ISO). 

[0028] Typically, magnetic stripe information is formatted in 

three tracks. Certain industry information must be main- 
tained on certain portion of the tracks, while other por- 
tions of the tracks may have open data fields. The con- 
tents of each track and the formatting of the information 
provided to each track is controlled by ISO standard ISO/ 
IEC 7811. For example, the information must typically be 
encoded in binary. Track 1 is usually encoded with user 
information (name) in alphanumeric format. Track 2 is 
typically comprised of discretionary and non-discretionary 
data fields. In one example, the non-discretionary field 



may comprise 19 characters and the discretionary field 
may comprise 13 characters. Track 3 is typically reserved 
for financial transactions and includes enciphered ver- 
sions of the user's personal identification number, country 
code, currently units amount authorized per cycle, sub- 
sidiary accounts, and restrictions. 
[0029] As such, where information is provided in accordance with 
this invention, it may be provided in magnetic stripe for- 
mat track. For example, the counter values, authentication 
tags and encrypted identifiers, described herein, may be 
forwarded encoded in all or a portion of a data stream 
representing data encoded in, for example, track 2 or 
track 3 format. 

[0030] Further still, various components may be described herein 
in terms of their "validity." In this context, a "valid" com- 
ponent is one which is authorized for use in completing a 
transaction request in accordance with the present inven- 
tion. Contrarily, an "invalid" component is one which is 
not authorized for transaction completion. In addition, an 
invalid component may be one which is not recognized as 
being permitted for use on the secure RF system de- 
scribed herein. 

[0031] Figure 1 illustrates an exemplary secure RFID transaction 



system 100 in accordance with the present invention, 
wherein exemplary components for use in completing a 
RF transaction are depicted. In general, system 100 may 
include a RFID transaction device 102 in RF communica- 
tion with a RFID reader 104 for transmitting data there 
between. The RFID reader 104 may be in further commu- 
nication with a merchant point of sale (POS) device 106 for 
providing to the POS 106 data received from the RFID 
transaction device 102. The POS 106 may be in further 
communication with an acquirer 110 or an account issuer 
112 via a network 108 for transmitting transaction re- 
quest data and receiving authorization concerning trans- 
action completion. 
[0032] Although the point of interaction device (POS) is described 
herein with respect to a merchant point of sale (POS) de- 
vice, the invention is not to be so limited. Indeed, a mer- 
chant POS device is used herein by way of example, and 
the point of interaction device may be any device capable 
of receiving transaction device account data. In this re- 
gard, the POS may be any point of interaction device en- 
abling the user to complete a transaction using a transac- 
tion device 102. The POS device 106 may receive RFID 
transaction device 102 information and provide the infor- 



mation to host network 108 for processing. 

[0033] As used herein, an "acquirer" may be a third-party entity 
including various databases and processors for facilitating 
the routing of a payment request to an appropriate ac- 
count issuer 112. The acquirer 112 may route the pay- 
ment request to the account issuer in accordance with a 
routing number provided by the RFID transaction device 
102, where the routing number corresponds to the ac- 
count issuer 112. The "routing number" in this context 
may be a unique network address or any similar device for 
locating an account issuer 112 on a network 108. Tradi- 
tional means of routing the payment request in accor- 
dance with the routing number are well understood. As 
such, the process for using a routing number to provide 
payment request will not be discussed herein for brevity. 

[0034] | n addition, the account issuer 112 ("account provider") 
may be any entity which provides a transaction account 
useful for facilitating completion of a transaction request. 
The transaction account may be any credit, debit, loyalty, 
direct debit, checking, or savings, or the like. The term "is- 
suer" or "account provider" may refer to any entity facili- 
tating payment of a transaction using a transaction device, 
and which includes systems permitting payment using at 



least one of a preloaded and non-preloaded transaction 
device. Typical issuers may be American Express, Master- 
Card, Visa, Discover, and the like. In the preloaded value 
processing context, an exchange value (e.g., money, re- 
wards points, barter points, etc.) may be stored in a 
preloaded value database (not shown) for use in complet- 
ing a requested transaction. The preloaded value database 
and thus the exchange value may not be stored on the 
transaction device itself, but may be stored remotely, such 
as, for example, at the account issuer 112 location. Fur- 
ther, the preloaded value database may be debited the 
amount of the transaction requiring the value to be re- 
plenished. The preloaded value may be any conventional 
value (e.g., monetary, rewards points, barter points, etc.) 
which may be exchanged for goods or services. In that re- 
gard, the preloaded value may have any configuration as 
determined by the issuer system 112. 
[0035] | n general, during operation of secure system 100, the 
RFID reader 104 may provide an interrogation signal to 
transaction device 102 for powering the device 102 and 
receiving transaction device related data. The interroga- 
tion signal may be received at the transaction device an- 
tenna 120 and may be further provided to a transponder 



(not shown). In response, the transaction device processor 
114 may retrieve a transaction device identifier from 
transaction device database 116 for providing to the RFID 
reader to complete a transaction request. Typically, the 
transaction device identifier may be encrypted prior to 
providing the device identifier to a modulator/demodu- 
lator (not shown) for providing the identifier to the RFID 
reader 104. 

[0036] | t should be noted that the RFID reader 104 and the RFID 
transaction device 102 may engage in mutual authentica- 
tion prior to transferring any transaction device 102 data 
to the reader 104. For a detailed explanation of a suitable 
mutual authentication process for use with the invention, 
please refer to commonly owned U.S. Patent Application 
No. 10/340,352, entitled "System and Method for Incent- 
ing Payment Using Radio Frequency Identification in Con- 
tact and Contactless Transactions," filed January 10, 2003, 
incorporated by reference in its entirety. 

[0037] | n accordance with the present invention, a RF transaction 
using a RFID transaction device is secured by limiting the 
number of transactions which may be performed with a 
particular transaction device. Once the maximum transac- 
tions value is reached, the transaction device may auto- 



matically disable itself against further usage. Alternatively, 
the account issuer 112 may flag the transaction account 
correlating to the transaction device such that the account 
issuer system automatically prevents completion of trans- 
actions using the transaction device. 

[0038] As such, the RFID transaction device 102 in accordance 
with the present invention further includes a transaction 
counter 118 for recording and reporting the number of 
transactions performed with a particular transaction de- 
vice 102. The counter 118 may be any device capable of 
being initiated with a beginning value and incrementing 
that value by a predetermined amount when the transac- 
tion device is presented for completion of a transaction. 
The counter 118 may be a discrete electronic device on 
the transponder, or may be software or code based 
counter as if found in the art. 

[0039] The initial counter value may be any value from which 

other similar values may be measured. The value may take 
any form, such as, alpha, numeric, a formation of sym- 
bols, or any combination thereof. 

[0040] jo facilitate understanding, the following description dis- 
cusses all values to be in numeric units (0, 1, 2, 3...n). 
Thus, the counter values, the value amount to be incre- 



merited, the total transactions counted value, and the 
maximum transactions value, are all whole numbers. 
[0041] | t should be noted that the account issuer 112 may preset 
the initial counter value at any initial value as desired. The 
account issuer 112 may also predetermine the value 
amount to be incremented by the counter when the trans- 
action device is used to complete a transaction. Further, 
the account issuer 112 may assign different values to be 
incremented for each distinct transaction device 102. Fur- 
ther still, the account issuer may determine the maximum 
transactions value, which may be particular to each indi- 
vidual transaction device 102 issued by the account issuer 
112. Where a maximum transactions value is equaled by 
the counter 118 value, the system 100 prevents the usage 
of the transaction device 102 to complete additional 
transactions. The usage of the transaction device 102 may 
be prevented by account issuer 112 where the account is- 
suer flags the transaction account corresponding to the 
transaction device 102, thereby preventing authorization 
for using the account to complete transactions. Alterna- 
tively, the transaction device 102 may self-disable. For 
example, the counter 118 may provide the transaction de- 
vice processor 114 a signal to which the processor 114 is 



responsive for preventing the transfer of transaction de- 
vice 102 identifier. 

[0042] For example, the account issuer 112 may preset the initial 
counter value at 5 units and the counter value to be incre- 
mented at 10 units per transaction. The account issuer 
112 may determine that transaction device 102 may be 
used to complete a total transaction value of 20 transac- 
tions. Since the counter 118 increments the counter value 
by the value to be incremented (e.g., 10 units) for each 
transaction, then for a total of 20 transactions permitted, 
the maximum transactions value will be 205 units. Once 
the counter value equals 205 units, then the operation of 
the transaction device 102 is disabled. 

[0043] The operation of the exemplary embodiment described 
above, may be understood with reference to Figure 1 and 
to the method of securing a RF transaction described in 
Figure 2. The operation may begin when the transaction 
device 102 is presented for completion of a transaction. 
The transaction device may be placed in an interrogation 
field generated by a RFID reader 104 (step 202). The RFID 
reader 104 may interrogate the RFID transaction device 
102 enabling device 102 operation. In response, the RFID 
transaction device 102 may retrieve the transaction device 



102 identifier, the account issuer 112 routing number and 
encrypted transaction device identifier from database 116 
for providing to RFID reader 104 (step 204). 
[0044] once the RFID transaction device 102 detects the interro- 
gation signal provided by the RFID reader 104, the 
counter 118 may increment its counter value (step 206). 
The counter 118 value may be incremented by an amount 
predetermined by the account issuer 112 (e.g., value 
amount to be incremented). The resulting counter 118 
value after incrementing is the total transactions counted 
value. 

[0045] upon determining the total transactions counted value, 
the RFID transaction device 102 may provide the total 
transactions counted value, the encrypted transaction de- 
vice 102 identifier, and the account issuer 112 routing 
number to the RFID reader 104 via RF transmission (step 
208). The RFID reader 104 may, in turn, convert the trans- 
action device 102 identifier, routing number, and total 
transactions counted value into merchant POS recogniz- 
able format and forward the converted information to the 
merchant POS 106 (step 210). The merchant system in- 
cluding the POS 106 may then provide a transaction re- 
quest to an acquirer 110 via network 106. The transaction 



request may include the information received from the 
transaction device 102 along with information (e.g. 
amount, number of product, product/service identifier) 
concerning the transaction requested to be completed 
(step 216). 

[0046] The acquirer 110 may receive the transaction request and 
forward the transaction request to the appropriate ac- 
count issuer 112 in accordance with the routing number 
provided (step 218). The account issuer may then identify 
that a transaction request is being provided that relates to 
a transaction device. For example, the merchant POS 106 
may provide a code appended to the transaction request 
specially configured for identifying a transaction device 
transaction which may be recognized by the account is- 
suer 112. Alternatively, the transaction device identifier, 
or a portion thereof, may be identified by the account is- 
suer 112 as originating with a RFID transaction device 
102. 

[0047] | n one exemplary embodiment, the account issuer 112 re- 
ceives the transaction device 102 and checks to see if the 
transaction device identifier corresponds to a valid trans- 
action account maintained on the account issuer 112 sys- 
tem (step 220). For example, the account issuer 112 may 



receive the encrypted transaction device identifier and lo- 
cate the corresponding decryption key relating to the 
transaction account. If the encrypted ID is invalid, such as, 
for example, when the account issuer 112 is unable to lo- 
cate the corresponding decryption key, the account issuer 
112 may provide a "Transaction Invalid" message to the 
POS 106 (step 228). The transaction device 102 user may 
then be permitted to provide an alternate means of satis- 
fying the transaction, or the transaction is ended (step 
230). 

[0048] |f the RFID transaction device encrypted identifier corre- 
sponding decryption key is located, the encrypted identi- 
fier is considered "valid" and the account issuer 112 may 
then use the corresponding decryption key to "unlock" or 
locate the transaction device account correlative to the 
transaction device 102. The account provider 112 may 
then retrieve all information relating to the usage limits 
which have been predetermined by the account issuer 
112. The account issuer 112 may be able to determine if a 
particular transaction device 102 has reached its limit of 
available transactions. 

[0049] For example, account issuer 112 may check to see if the 
total transactions counted value equals or exceeds the 



maximum transactions allowed (step 224). If the maxi- 
mum transactions allowed have been reached then the 
counter value is met or exceeded, and the transaction is 
considered "invalid." As such, the account issuer 112 may 
then provide a "Transaction Invalid" message to the POS 
106 (step 228). In addition, the account issuer 112 may 
determine whether the total transactions counted value is 
the next expected value. If not, then the transaction is 
considered "invalid" and the account issuer 112 may also 
provide a "Transaction Invalid" message to the POS 106 
(step 228). The transaction device 102 user may then be 
permitted to provide alternate means of completing the 
transaction (step 226) or the transaction is ended. 

[0050] Alternatively, where the total transactions counted value 
does not exceed or meet the maximum transactions al- 
lowed value, the counter value is considered valid and a 
"Transaction Valid" message is sent to the merchant POS 
106 (step 230). The merchant may then complete the 
transaction under business as usual standards as are em- 
ployed by the merchant. 

[0051] | n accordance with the various embodiments described, 

the present invention addresses the problem of securing a 
RF transaction completed by a RFID transaction device. 



The invention provides a system and method for an ac- 
count issuer to determine if the RFID transaction device is 
a valid device for completing a transaction on a RF trans- 
action system. The account issuer can determine whether 
the transaction device is valid by verifying the transaction 
device counter, and encryption identifier. It should be 
noted, however, that the present invention contemplates 
various arrangements wherein the transaction device may 
be validated. 

[0052] The preceding detailed description of exemplary embodi- 
ments of the invention makes reference to the accompa- 
nying drawings, which show the exemplary embodiment 
by way of illustration. While these exemplary embodi- 
ments are described in sufficient detail to enable those 
skilled in the art to practice the invention, it should be 
understood that other embodiments may be realized and 
that logical and mechanical changes may be made without 
departing from the spirit and scope of the invention. For 
example, the RFID reader may include an RFID reader en- 
crypted identifier stored in the reader database, which 
may be validated by the account issuer in similar manner 
as with the transaction device encrypted identifier. More- 
over, the counter may increment the total transactions 



counted value by the predetermined incremental value at 
the completion of a successful transaction. In addition, 
the steps recited in any of the method or process claims 
may be executed in any order and are not limited to the 
order presented. Further, the present invention may be 
practiced using one or more servers, as necessary. Thus, 
the preceding detailed description is presented for pur- 
poses of illustration only and not of limitation, and the 
scope of the invention is defined by the preceding de- 
scription, and with respect to the attached claims. 



